Transaction approval system

ABSTRACT

An improved system is disclosed for detecting invalid transaction cards at remote transaction terminals. The system includes providing each terminal with a master table having data corresponding to invalid cards. The data in the master table is less than the actual account numbers of the invalid cards. By using a compressed version of the data, the file can be shortened to facilitate storage and transmission. The compressed data file is arranged such that when an invalid card is presented, it will be identified and routed on for further processing. In the preferred embodiment, the probability that a valid card will be identified as potentially invalid is on the order of one of three percent.

TECHNICAL FIELD

The subject invention relates to a financial transaction network. Theinvention includes an improved system for distributing information aboutinvalid transaction cards.

BACKGROUND OF THE INVENTION

In the last fifteen years the use of transaction cards as substitutesfor cash has greatly expanded. Along with this expanded use has come anincrease in losses due to fraud. One of the most costly problems iscaused by the use of invalid cards. The term invalid card includes thosecards which have been lost or stolen. The term can also include cardswhose credit limits have been exceeded by the holder. Significantefforts have been made to minimize the use and abuse of invalid cards.

One of the earliest approaches used to combat this fraud was todistribute a printed list of invalid cards. One such list is called theCard Recovery Bulletin or CRB. In use, the merchant checks the accountnumber on the card presented for the transaction with the accountnumbers printed in the CRB. If the account number is listed, thetransaction would be declined.

This use of the CRB is effective in reducing a large percentage of fraudlosses. Unfortunately, this approach has a few drawbacks. For example, atransaction card is often used almost immediately after it has been lostor stolen. This immediate use will occur before the card has been listedin the bulletin or before the bulletin has been distributed. Anotherproblem with this approach is that from a practical standpoint, it isoften difficult to insure that store clerks use the list properly or atall.

Because of these difficulties, many other more sophisticated approacheshave been taken. One of the most effective schemes is to authorize everytransaction through a real-time, on-line communications network. Forexample, the merchant can report the account number of the cardpresented for a transaction to a central processor by telephone. Theaccount number on the card can then be checked against a current list ofinvalid card numbers stored either at the central processor or back atthe card issuer. In another variation on this scheme, a transactionterminal is provided with a card reader which reads a magnetic stripeencoded with an account number. The terminal can then automaticallytransmit the account number to the central processor for approval.

This on-line scheme eliminates the lag time inherent in using the CardRecovery Bulletin. Unfortunately, a fully on-line system turns out to beprohibitively expensive and prone to communication delays. An on-lineapproach also does not provide any protection when the network is down.

More recently, many approaches have been taken to reduce transactionapproval costs while also controlling fraud losses. As microprocessorsbecome smaller, cheaper and faster, some of the transactional analysiscan be performed at the terminal itself. Efforts have been made todevelop screening procedures that avoid having to transmit thetransaction information to the central processor. For example, thetransaction terminal can be programmed to authorize every transactionbelow a certain dollar limit or floor limit. In this manner, the cost ofcommunication can be balanced against the risk of loss.

The terminal may also be provided with the capability to verify acardholder secret personal identification number or PIN. In thisscenario, a version of the PIN is encoded onto the magnetic stripe onthe card and read by the terminal. The terminal then compares the PINread from the card with a PIN entered into a keypad on the terminal bythe cardholder. If the two PINs match, the transaction can be approved.The use of PINs sharply reduces the fraudulent use of lost or stolencards.

A more sophisticated approach is described in copending U.S. patentapplication Ser. No. 730,309, filed May, 2, 1985, assigned to the sameassignee as the subject invention and incorporated herein by reference.In this patent application, a system is described wherein riskassessment data is encoded onto the card by the card issuer. This riskassessment data is tailored to define the credit worthiness of eachspecific cardholder. This risk assessment data can be analyzed by thetransaction terminal and if the transaction amount falls within theparameters encoded on the card by the issuer, the transaction can beautomatically approved. If the transaction amount exceeds theseparameters, the transaction information is routed on to the centralprocessor for further analysis.

As the cost of computer memory space has decreased, the idea of storingthe account numbers of invalid cards in each transaction terminal hasbeen explored. If this scheme were implemented, the account number ofthe card being presented for the transaction could be automaticallycompared at the terminal. One prior art system which utilized thisapproach is described in U.S. Pat. No. 3,696,335, issued Oct. 3, 1972 toLemelson.

The approach illustrated in the Lemelson patent has been deemedimpractical for a number of reasons. More specifically, in order to keepthe lists current, they would have to distributed to the terminals andupdated on a frequent basis. With the number of transaction terminalsrapidly expanding, it would be virtually impossible to physicallytransfer this data to the terminals on a routine basis. Therefore,distribution of the list of invalid account numbers must be through sometype of communication link. Unfortunately, the lists of invalid cardsare so large for the major transaction card systems that on-linedistribution becomes quite difficult. However, if some way could bedeveloped to distribute the list in an efficient manner, this approachcould be very effective in reducing both communication costs and fraudlosses.

One technique for attaining this goal is described in U.S. Pat. No.4,558,211, issued Dec. 10, 1985 to Berstein. This disclosureacknowledges that a complete "hot card" list would be too large totransmit to each transaction terminal. The solution proposed in thelatter patent is to add an identifier to each listed hot card whichindicates the geographical location in which the card is most likely tobe used. Subsets of the hot card list geared to specific geographicallocations can then be generated. The greatly shortened lists can then bedistributed to the terminals and stored. The patent suggests that astandard 4K byte memory in a terminal could hold a list of 800 invalidcards. Since most invalid cards are used in the area where they werelost or stolen, this approach could be very effective as long as only800 invalid cards exist in any geographical area.

Unfortunately, major transaction card companies will typically have overone million invalid cards listed on any given day in the United Statesalone. Even when these lists are broken down geographically, the size ofthe smallest list does not fall much below 100,000 cards. Obviously, ifthe geographical area is made too small, the effectiveness of the systemwill be reduced since it will be limited to catching an unauthorizeduser only at the exact location the card was lost or stolen.

Accordingly, it is the object of the subject invention to provide a newsystem for distributing information about invalid cards.

It is another object of the subject invention to provide a new systemfor distributing lists of invalid cards which can be used to authorizetransactions at a transaction terminal.

It is a further object of the subject invention to provide a new systemfor distributing lists of invalid cards in a cost effective manner.

It is still another object of the subject invention to provide a newsystem for rapidly distributing lists of invalid cards in an on-linemanner.

It is still a further object of the subject invention to provide a newdata file containing information about invalid cards that takes up verylittle memory space.

It is still another object of the subject invention to provide acompressed data file that can be easily transmitted to remotetransaction terminals.

It is still a further object of the subject invention to proved acompressed data file which will always indicate when an invalid card hasbeen presented and wherein the probability of identifying a valid cardas a potentially invalid card is on the order of one to three percent.

It is still another object of the subject invention to provide a hotcard authorization system that can easily be implemented in currentmicroprocessor based remote transaction terminals.

It is still a further object of the subject invention to provide acompressed data file with information on an invalid transaction that isarranged in a manner such that the entire file does not have to besearched in order to determine if a particular account number isinvalid.

SUMMARY OF THE INVENTION

In accordance with these and many other objects, the subject inventionprovides for a method for generating and distributing a master tablecontaining information about invalid cards. A unique data compressionmethod is used to substantially reduce the amount of memory needed tohold the master table. By reducing the size of the file, the downloadingof the information to local transaction terminals is greatlyfacilitated.

The information contained in the master file is less than the actualaccount numbers of the invalid cards. Nonetheless, the data is soarranged that if an invalid card is presented to a transaction terminal,it will always be identified as requiring further analysis prior toapproval. If the card is so identified, the account information can thenbe transmitted to a central processor for final confirmation against acomplete invalid card list. Conversely, if an account number is testedagainst the master file at the transaction terminal and is cleared, thetransaction can safely be approved off-line since this result insuresthat the account number is not listed in the invalid card file.

Because of the characteristics of the data compression system of thesubject invention, a certain percentage of valid cards which arepresented will be identified as potentially invalid. In such cases, theinformation about the transaction will be passed on to the centralprocessor for absolute verification. The probability of a valid cardbeing identified as potentially invalid can be adjusted by varying thecharacteristics of the master table. The probability of a valid cardbeing identified as potentially invalid should be less than ten percentand preferably on the order of one to three percent. Since manytransactions are transferred to the central processor for other reasons(i.e. high dollar amount transactions which exceed the floor limit ofthe terminal), the fact that a small percentage of transactions are sentto the central processor under this scheme will have an insignificantimpact on overall system performance.

The master table is defined by a plurality of bit maps. As discussed indetail below, by using a plurality of bit maps in the master tableinstead of just one, the probability of a valid card being identified aspotentially invalid can be reduced. Conversely, as the number of bitmaps is increased, processing time is also increased.

Each of the bit maps in the table is B bits in length. Information aboutthe invalid cards is represented by indicators within the bit map. Inorder to set the indicators, the account number of the invalid card issubjected to an algorithmic function to generate an index value betweenzero and the number of bits in the bit map. When this value is obtained,an indicator is placed in the location in the bit map corresponding tothe index value that is generated. In the illustrated embodiment, wherefive bit maps are used, the account number is subjected to fivedifferent algorithmic procedures to generate five different indexvalues, each of which is used to place an indicator in one of the fivebit maps.

The algorithm used to generate an index value may be relativelysophisticated, such as the data encryption standard (DES). For greaterspeed and simplicity, selected digits of the account number can be mixedand added to generate an index value. The process of mathematicallyreducing the information content in a data stream is typically called"hashing".

The selected hashing procedures are repeated for each of the invalidcards on the list. When the table is complete, it is distributed to thetransaction terminals. In the preferred embodiment, this list isdownloaded by radio transmission to all terminals simultaneously. Thislist can be downloaded through any other suitable type of communicationlink.

In operation, the account number of the card presented for thetransaction is read into the terminal. The terminal then performs thesame algorithmic steps, or, hashing on the new account number that wasdone to create the table in the first place. An index value is generatedfor each bit map. The transaction terminal then determines if anindicator is present in each bit map in the master table correspondingto each of the newly generated index values. If any bit map does notcontain an indicator, then the card is immediately known to be valid andthe transaction may be approved offline. If the comparison reveals thatthe indicators are present in every bit map, then there is a possibilitythat an invalid card has been presented. In this case, some form offurther processing will be required. At that point, the transaction maybe routed to the central processor for an absolute comparison of theaccount numbers against the entire list of invalid cards. If thetransaction system happens to be down, a message may be relayed to theoperator that the account number should be checked against a printedlist. As pointed out above, the terminal will identify some smallpercentage of valid cards as potentially invalid but the results offurther processing will indicate that those cards so identified are infact valid and that the transaction should proceed.

It is estimated that a master table generated with the subject datacompression system will be one-fourth to one-sixth the length of a listof actual invalid account numbers. This shorter file can be more easilytransmitted and stored. Another advantage to this approach is that theentire table does not have to be scanned to determine if a card isvalid. The index values are used to pinpoint specific locations in thetable. As soon as such a location is encountered in which no indicatoris present, the card in question is immediately known to be valid.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating a transaction network wherethe method of the subject invention can be implemented.

FIG. 2 is a representation of a master table having five bit maps.

FIG. 3 is a representation of the last 12 digits of an invalid accountnumber.

FIG. 4 is a flow chart illustrating the steps taken at the transactionterminal in accordance with the subject invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to FIG. 1, there is illustrated a transaction network in whichthe subject invention may be implemented. As shown in FIG. 1, atransaction network typically will include one or more issuers 10 oftransaction cards. The transaction cards are distributed to customersand will include an account number identifying the cardholder. The cardsare presented to merchants for goods and services in lieu of cash.

The transaction is frequently authorized through the use of transactionterminals 20. There are a large number of transaction terminalspublically available and therefore they will not be described in detailherein. The current state of the art transaction terminal typicallyincludes a card reader for reading account information and other datafrom the magnetic stripe on the transaction card. The terminal can alsobe provided with the ability to automatically dial and make an onlineconnection to a computer located either at a merchant bank, a networkswitch or to one of the card issuers. For the purposes of thisdisclosure, block 30, labelled "CPU," is intended to correspond to acentral processing unit having higher level decision-making authority.For example, the central processing unit 30 can have stored therein afull list of invalid cards 32 which may be consulted to determine if thetransaction should be approved.

As discussed above, the transaction terminal 20 may be provided with theability to perform some transactional analysis without connection to themain CPU 30. To carry out these functions, the terminals will include amicroprocessor, dedicated ROMs, random access memories, a keypad anddisplay. In order to perform the subject invention, some dynamic memoryspace must be allocated for holding the master table 40. In addition, aprogram must be provided for analyzing the account number presented withthe data in the master table. The programming of a terminal to performthese functions is well within the abilities of one skilled in thesoftware development art.

In accordance with the subject invention, the terminal 20 is capable ofdetermining whether a card, presented for a transaction, is likely to beinvalid. This result was achieved in the above cited U.S. Patents. Inthe prior art systems, actual invalid account numbers are supplied toeach transaction terminal. The account number of the card presented iscompared to the account numbers listed in the memory to determine if thetransaction should be approved. In contrast, in the subject invention, amaster table containing information less than the invalid accountnumbers is generated and supplied to the terminals. In this manner,meaningful data can be stored in less space. In addition, only preciselocations in the table are searched to determine if the card is invalid.

In accordance with the subject invention, the information on the invalidcards is contained in a master table 40 generated at the centralprocessor 30. An example of a master table 40 is shown in detail in FIG.2. The master table consists of at least one bit map of B bits inlength. Preferably, a plurality of bit maps are used. As will be seenbelow, by using a plurality of bit maps in the master table instead ofjust one, the probability of a valid card being identified aspotentially invalid is decreased. In the illustrated embodiment of FIG.2, five bit maps are used.

When selecting the length of the bit map, consideration should be givento maximizing the information content within the map. From a statisticalanalysis, it can be shown that greatest information content in a bit mapoccurs when roughly half the bits are zero and half the bits are one.Assuming that the algorithmic functions used to generate the tableprovide results with pseudo-random characteristics, the fraction of bitsin a bit map which are zero is given by the following equation:

    Z=[1-(1/B)].sup.N                                          (1)

where Z is the fraction, B is the number of bits in the map and N is thenumber of invalid cards listed. Where each bit map is 200,000 bits inlength, a distribution profile where half the bits are zero and half thebits are one (Z=0.5) would occur when about 138,000 account numbers arelisted. In the illustrated embodiment, where roughly 100,000 cards areinitially listed, the probability of any bit being a one is on the orderof 0.4. In operation, as account numbers are added to the master tablethrough an update procedure discussed below, the information content inthe bit map will increase as the probability increases to 0.5.

In order to generate the table, the account numbers of the invalid cardsare "hashed" to derive compressed data. An account number can be hashedby encrypting the number using the data encryption standard (DES) and asecret key. The resulting number can be truncated to an index valuebetween zero and B-1. An indicator, (for example, a "one" if all thebits are originally set to "zero") can then be placed in the bit map atthe location corresponding to the index value which has been generatedby the algorithmic function. If more than one bit map is used, theaccount number could be encrypted again, using a different key. Theresult is truncated to obtain another index value which will be used toplace an indicator in the second bit map. This process would berepeated, encrypting the account number one time for each bit mappresent in the master table. Each invalid card would then have oneindicator in each of the bit maps. Similar steps would be performed foreach invalid card, and indicators would be added into the table. If anindicator was already located at an index value from a previous card,this indicator would remain unchanged.

While the data encryption standard (DES) provides a method of hashingaccount numbers which has suitable pseudo-random characteristics, it isalso time-consuming and complex. In the illustrated embodiment, asimpler and faster hashing algorithm is described which has anacceptable degree of pseudo-random characteristics. In this context, apseudo-random algorithmic function will insure that any index valuegenerated from the account number will have an equal probability oflying anywhere in the bit map. Furthermore, the results of thealgorithmic function used with one bit map should not correspond in anyway to the results of the algorithmic function used t generate adifferent bit map.

In the illustrated embodiment, these factors are balanced by selectingand combining small groups of digits in the account number to createindex values. This approach can best be understood by referring to FIG.3 and the tables below. FIG. 3 illustrates the last 12 digits of anaccount number 0358-2314-2787. The position of these digits has beenlabelled 1 to 12, from right to left. Where the bit map has 200,000entries, index values between 0 and 199,999 must be generated. The mostsignificant digit of that six-digit index value must be either a one ora zero. The remaining five digits must be between 0 and 9.

The first index value which will be used to place an indicator in thefirst bit map in FIG. 2, can be generated using Table I, which is merelyintended to illustrate a suitable hashing function.

                  TABLE I                                                         ______________________________________                                        INDEX   ACCOUNT                                                               VALUE   NUMBER      CORRESPONDING  INDEX                                      DIGIT   POSITIONS   ACCOUNT DIGITS VALUE                                      ______________________________________                                        1       (4 & 5)     (2 + 4)        0                                          2       (1, 7 & 8)  (7 + 3 + 2)    2                                          3       (2, 4 & 9)  (8 + 2 + 8)    8                                          4       (2, 5 & 10) (8 + 4 + 5)    7                                          5       (3, 6 & 11) (7 + 1 + 3)    1                                          6       (3, 7 & 12) (7 + 3 + 0)    0                                          ______________________________________                                    

As seen from Table I above, the first digit is derived based uponwhether the sum of two digits in the account number is even or odd. Inthis example, in index digit 1, the two account number digits selected(2, 4) are in the fourth and fifth position. Since 2 plus 4 is even, thefirst digit of the index value will be 0. Digit 2 of index 1 is themodulo 10 summation of the account number digits located at positions 1,7 and 8, namely, 7, 3 and 2. The sum of 7+3+2 equals 12, with the modulo10 sum being 2, such that digit 2 of the index value is 2. Similarly,digit 3 is the modulo 10 sum of 8+2+8 (positions 2, 4 & 9), which isequal to 8. Therefore, the third digit in the index is 8. The remainingdigits are calculated in a similar manner to yield digits 7, 1 and 0.When read together, the index value for the account number in FIG. 3 is028170. An indicator will then be placed in the first bit map at the28,170th bit. If an indicator is already present at that bit from aprevious table entry, no change will be made.

Similar index values are then calculated for each of the bit mapspresent in the master table. In the preferred embodiment with 5 bitmaps, another four index values will be generated. A table will be usedfor each index value that is similar in structure, but different incontent to the table illustrated above. The index digits selected forthe tables will preferably be as different from each other as possible.

A second table (Table II) is set forth below as another illustrativeexample:

                  TABLE II                                                        ______________________________________                                        INDEX   ACCOUNT                                                               VALUE   NUMBER      CORRESPONDING  INDEX                                      DIGIT   POSITIONS   ACCOUNT DIGITS VALUE                                      ______________________________________                                        1       (2 & 6)     (8 + 1)        1                                          2       (4, 5 & 8)  (2 + 4 + 2)    8                                          3       (1, 3 & 9)  (7 + 7 + 8)    2                                          4       (3, 5 & 10) (7 + 4 + 5)    6                                          5       (2, 7 & 11) (8 + 3 + 3)    4                                          6       (4, 6 & 12) (2 + 1 + 0)    3                                          ______________________________________                                    

When the account number shown in FIG. 3 (0358-2314-2787) is hashed inaccordance with the algorithm of Table II, an index value of 182,643 isgenerated. An indicator would then be placed in the 182,643rd bit of theassociated bit map.

By generating a master table in this fashion, an indicator will beplaced in each bit map for each invalid card. When the table is used todetect an invalid account number (a process described in greater detailbelow) an indicator must be present in each bit map tested, otherwisethe card is known to be valid. The converse of this statement is nottrue. More specifically, even if an indicator is present in each bitmap, the card might still be valid. As can be appreciated, as moreinvalid cards are listed in the table, and more indicators are added tothe bit map based on the results of random algorithmic functions, thelikelihood that indicators will be present for the index values obtainedby hashing any account number will increase.

The probability that an unlisted valid account number will be identifiedas potentially invalid is given by the following formula:

    P=[1-(1-1/B).sup.N ].sup.M                                 (2)

where P is equal to the probability, B is equal to the number of bits ineach map, N is equal to the number of listed account numbers, and M isequal to the number of bit maps. In the arrangement shown herein, wherefive bit maps are used, each 200,000 bits long, if 200,000 accountnumbers are listed, the probability of a valid card being identified aspotentially invalid would be on the order of 10.1 percent. If the fileis reduced to 100,000 account numbers, the probability of identifying avalid card as potentially invalid drops to just below one percent.

The probability of identifying a valid card as potentially invalid canbe varied by changing the total number of bit maps in the master table.Assuming that the length of the bit map has been adjusted to maximizeinformation content (as discussed above) the probability that a validaccount number will be identified as potentially invalid is given by thefollowing equation:

    P=1/2.sup.M                                                (3)

This equation demonstrates that when five bits maps are used, theprobability of identifying a valid card as potentially invalid is 1 in32 or about 3.1 percent. In the illustrated embodiment, where only100,000 cards are initially listed, the bit maps are not utilized totheir full information carrying capacity and the probability ofidentifying a valid card as potentially invalid is just under onepercent as noted above.

From a purely statistical analysis, if 100,000 invalid cards are to belisted in a master table one million bits long, seven bit maps should beused. To implement such a master table, a hashing algorithm which willrandomly distribute information within seven bit maps, each 142,857 bitslong, must be created. For practical reasons, five bit maps wereselected for this illustration since a suitable hashing algorithm couldbe created more readily. Furthermore, while the use of five bit mapsinstead of seven in the master table will result in an increase in thepercentage of valid cards that are identified as potentially invalid,this increase is relatively small and not considered unacceptable.Finally, the use of five bit maps allows the number of listed accountnumbers to increase to about 140,000 with the probability of identifyinga valid card as potentially invalid increasing to only about 3.25percent.

The effect of the subject data compression system can be compared withlisting the actual account numbers in a memory. For the comparison, theleast 12 significant digits of the account number are selected. Each 12digit account number would require 48 bits of memory, assuming four bitsper digit in a binary coded decimal format. In contrast, in the subjectsystem, reasonable operation is achieved when the number of bits in themaster table is roughly seven to ten times greater than the number ofinvalid account numbers to be listed. This represents a reduction inmemory needs by roughly factor of five and balances the competingfactors of limited memory and information content.

In practice, the list of invalid cards used to generate the table canalso be trimmed with respect to the geographical location of the invalidcards in a manner similar to that described in the Berstein patent.However, rather than distributing these reduced lists as called for inthe Berstein patent, the lists are used to generate a plurality ofmaster tables which are then distributed geographically. In this manner,the total list of invalid cards, which may exceed one million in theUnited States alone, can be broken into regional subsets having a lengthon the order of 100,000 cards each. This master table can be one millionbits or 125 K-bytes long. 128K dynamic RAM memories are readilyavailable at relatively low cost and can easily store this size mastertable. More importantly, the reduced size of the master files simplifiesand shortens the time necessary to transmit the information to theterminals.

The transmission of the master table to each individual terminal couldbe done along the same type of communication lines used to interconnectthe terminal and the central processor unit for on-line authorizations.These lines are shown as 50 in FIG. 1. In this approach, a communicationprotocol must be established with each terminal to send the information.In the preferred embodiment of the subject invention, the master table40 is broadcast over radio waves to the terminal. As shown in FIG. 1,the CPU is connected to a transmitter 60. Transmitter 60 generates radiowaves which are received by the antenna 72 of radio receiver 70 providedin each terminal. The information received by the receiver is downloadedinto memory in each terminal. Information on radio waves can be readilytransmitted at 38,400 bits per second such that the entire one millionbit master file could be transmitted in less than one-half a minute.This file could be generated and transmitted once a day so that the mostcurrent information on invalid cards is available to the terminals.

If less frequent transmission of the entire master table is desired, thetable can be updated with additions. For example, if the master table istransmitted weekly, updates could be transmitted on a daily basis. Inthis case, lists of additional invalid cards could be supplied to eachterminal. Each newly transmitted invalid account umber would be hashedby the individual terminal and indicators would be placed into the bitmaps of the master table.

If the system is operated in a manner where a significant number of newentries are typically supplied to the terminal prior to retransmittingan entirely new master table, steps can be taken to reduce thetransmission time of the updates. For example, when the table isinitially created, each twelve digit account number could be "prehashed"to yield a seven digit number. This seven digit number would then behashed to create index values in a manner similar to that describedabove. If the master table is created in this manner, only the sevendigit, prehashed account numbers, rather than the full twelve digitnumbers, would have to be supplied to the transaction terminals when themaster table is updated. This approach would shorten transmission timeby almost one-half.

It should be noted that while individual account numbers can be added tothe master table, individual account numbers cannot be deleted. As canbe appreciated, any time a file is created by data compression, therewill be duplicates or overlapping entries. Therefore, even if aparticular card has regained valid status (or the listing period hasexpired), the indicators could not be safely removed from the filewithout unintentionally destroying other meaningful data.

Effective deletion of account numbers can only be achieved bytransmitting a newly generated master file. Transmission of a new masterfile should occur before the number of account numbers listed in thefile, as increased by updates, reaches a level where an unacceptablepercentage of valid cards are being identified potentially invalid.

Having described the generation and transmission of the master table tothe transaction terminals, the use of the master table at thetransaction terminal will now be discussed with reference to the flowchart of FIG. 4. At the time of a purchase, a cardholder will presenthis transaction card to a merchant. The account number of the card isthen supplied to the transaction terminal, as shown in step 100 in FIG.4. The processor in the transaction terminal can then generate indexvalues for each bit map in a manner exactly equivalent to the algorithmsused to generate the master table.

Assuming the hashing system described above has been used to create themaster table, the first digit of the first index value will be definedby whether the sum of digits in positions 4 and 5 are odd or even. Theremaining five digits of the first index value will be the modulo sum ofeach group of three selected digits. After the first index value isgenerated (step 102), the processor will look into the first bit map ofthe master table to determine if an indicator has been placed at thelocation defined by the index value(step 104). If there is no indicatorat that location in the first bit map, the analysis is complete and thetransaction can be allowed to continue (step 106).

Step 106 is intended to represent the next set of steps to which thetransaction would normally be subjected. For example, the transactionamount could be compared to a dollar limit stored either n the card asrisk assessment data or in the terminal. If the transaction falls belowthat dollar limit it could be automatically approved right at theterminal. If the transaction limit is above that amount, the transactioninformation may still be sent on to the central processor for furtheranalysis.

If an indicator is present in the first bit map, the analysis willcontinue for each remaining bit map. The processor will first determineif there are any bit maps remaining that have not been tested (step107). If there are any bit maps remaining, the processor will generatethe index value for the next bit map in step 108. The processor willcheck to determine if an indicator has been placed in the next bit mapof the master table at the location defined by the newly generated indexvalue (step 104). As noted above, if no indicator is present at thatlocation, the card is known to be valid and the transaction can proceed.(step 106)

If indicators are present in all of the bit maps, (i.e. there are nomore bit maps left to test and therefore the answer to decision step 107is "no") there is a possibility that the card is invalid and theinformation must be routed for further processing as shown in step 110.In this step, an on-line connection can be established to the centralprocessor 30. The transaction information is transmitted to the centralprocessor where it can be further analyzed. The analysis can be made atthe central processor if the list of all invalid cards is stored at thatlocation. In the alternative, where the invalid card lists are stored atthe issuers 10, the transaction can be rerouted for further analysis atthe issuer. If the card is, indeed, invalid, a return message can begiven to the terminal to decline the transaction. If, however, the cardis valid, the transaction can be approved.

As discussed above, the subject system provides a master table with alarge amount of information held in a small space. This approachdescribed herein, however, has an additional advantage. Morespecifically, in order to check any card against the master file, thereis no need to go through the entire table. In the system described inU.S. Pat. No. 3,696,335, where the list of actual account numbers issupplied to the terminal, the account number is compared to each of thenumbers in the list in order o determine if the card is listed. Even ifmore sophisticated binary searching algorithms are used (where lists arearranged in numeric order), a number of comparisons are still necessary.In contrast, in the subject system, only the location in the bit mapcorresponding to the index value must be checked to determine if anindicator is present. The entire bit map does not have to be reviewed.In a master table having five bit maps, a determination can be made asto whether an account number is present in a universe of 100,000 invalidcards simply by looking at five locations in the master table. If anyindicator is missing, the card is known to be valid.

In summary, there has been provided a new and improved system fordistributing information about invalid transaction cards. In thissystem, a master file is created containing less than the entire accountnumber of the cards. The master file consists of at least one bit maphaving indicators corresponding to invalid cards. The location of eachindicator is determined by hashing the account numbers to produce anindex value which is then used as an address for supplying the indicatorto the bit map. Once indicators have been placed in all the bit maps ofthe master table for all the invalid account numbers, the master tableis then transmitted to the transaction terminals. The transactionterminals which the information in the master table to analyze pendingtransactions. The information in the table is arranged such that if apotentially invalid card is presented, a signal will be generated whichwill cause the transaction to be passed onto the central processor forfurther analysis. In the preferred embodiment, the table is arrangedsuch that the probability of a valid card being identified aspotentially invalid is less than ten percent and preferably on the orderof one to three percent. In this manner, only a small percentage ofvalid transactions will be transmitted to the central processor forfurther analysis as a result of this scheme.

While the subject invention has been described with reference topreferred embodiments, it is apparent that other changes andmodifications could be made therein by one skilled in the art withoutvarying from the scope and spirit of the subject invention as defined bythe appended claims.

We claim:
 1. In a transaction network including a central processor, aplurality of transaction terminals and a plurality of transaction cards,each card having an account number associated therewith, a method foridentifying invalid cards comprising the steps of:(a) generating amaster table at said central processor, said table including at least afirst bit map B bits in length; (b) selecting a set of digits from theaccount number of a first invalid transaction card; (c) calculating afirst index value which is an algorithmic function of said set ofdigits, said first index value being between zero and B-1; (d) placingan indicator within said first bit map corresponding to said first indexvalue; (e) repeating steps b though d for each invalid card; and (f)supplying the master table to each transaction terminal whereby during atransaction, the transaction terminal determines if an indicator existsin the master table corresponding to the account number of the cardpresented for the transaction.
 2. A transaction network as recited inclaim 1 further including the steps at the transaction terminalof:repeating steps b and c for the account number of the card presentedto generate a first index value; determining if an indicator is presentin the first bit map at a location corresponding to the generated firstindex value.
 3. A transaction network as recited in claim 2 furtherincluding the steps at the transaction terminal of: allowing thetransaction to continue unless an indicator is present whereupon thetransaction is subjected to further verification.
 4. In a transactionnetwork including a central processor, a plurality of transactionterminals and a plurality of transaction cards, each card having anaccount number associated therewith, a method for identifying invalidcards comprising the steps of:(a) generating a master table at saidcentral processor, said table including a plurality of bit maps, eachmap being B bits in length; (b) selecting a set of digits from theaccount number of a first invalid transaction card; (c) calculating afirst index value which is an algorithmic function of said set ofdigits, said first index value being between zero and B-1; (d) placingan indicator within one of said bit maps, said indicator correspondingto said first index value; (e) repeating steps b and c for each bit mapin said master table, each time selecting a unique set of digits fromthe account number and placing an indicator corresponding to eachcalculated value in the associated bit map: (f) repeating steps b thoughe for each invalid card; and (g) supplying the master table to eachtransaction terminal whereby during a transaction, the transactionterminal determines if an indicator exists in the master tablecorresponding to the account number of the card presented for thetransaction.
 5. A transaction network as recited in claim 4 furtherincluding the steps at the transaction terminal of:repeating steps b andc for each bit map for the account number of the card presented togenerate a plurality of values; determining if indicators are present ineach bit map corresponding to the generated values.
 6. A transactionnetwork as recited in claim 5 further including the steps at thetransaction terminal of:allowing the transaction to continue unless anindicator is present in each bit map whereupon the transaction issubjected to further verification.
 7. In a transaction network includinga central processor, a plurality of transaction terminals and aplurality of transaction cards, each card having an account numberassociated therewith, a method for identifying invalid cards comprisingthe steps of:(a) generating a master table at said central processor,said table including data derived from a list of invalid transactioncards, said data being less than the entire account number of each cardand including at least one indicator for each invalid card; and (b)supplying the master table to each transaction terminal whereby during atransaction, the transaction terminal determines if an indicator existsin the master table for the account number of the card presented for thetransaction and allowing the transaction to continue unless an indicatoris present whereupon the transaction will be subjected to furtherverification.
 8. A system as recited in claim 7 wherein the entiremaster table does not have to be scanned to determine if an indicatorexists for the account number of the card presented for the transaction.9. A data file for use in transaction networks, said data file includinginformation about the account numbers of invalid transaction cardscomprising:a master table including a plurality of bit maps each havingB bits; and one indicator in each bit map for each invalid card, eachsaid indicator being at a location corresponding to an index value whichis an algorithmic function of a set of digits in the account number ofthe transaction card.
 10. A data file as recited in claim 9 wherein thelength of the bit maps in the master table are set with respect to thenumber of invalid transaction cards such that the probability of anindicator being present in a bit map is approximately 0.4 to 0.5.
 11. Adata file as recited in claim 10 wherein the number of bit maps in themaster table are selected such that the probability of a valid cardbeing represented as an invalid card in the data file is less than tenpercent.
 12. A data file as recited in claim 10 wherein the number ofbit maps in the master table are selected such that the probability of avalid card being represented as an invalid card in the data file is onthe order of one to three percent.
 13. A transaction system including acentral processor and a plurality of transaction terminals and aplurality of transaction cards each having an account number, and withsome of said cards being invalid, said system for facilitating off lineapproval of transactions comprising:means at said central processor forcreating a master table, said master table having a plurality of bitmaps, wherein one indicator is provided in each bit map for each invalidtransaction card; means for supplying the master table to each of thetransaction terminals; and means at each transaction terminal fordetermining if an indicator is present in each bit map for the accountnumber of the transaction card being presented.
 14. A transaction systemas recited in claim 13 wherein said means for supplying the master tableto the transaction terminals comprises:a radio transmitter; and areceiver located at each transaction terminal.
 15. A transaction systemas recited in claim 13 wherein said means at said central processorgenerates said master table by selecting sets of digits from the accountnumber of each invalid transaction card and calculating an index valuefor each set of digits which is an algorithmic function thereof andplacing an indicator in individual bit maps at locations correspondingto the calculated index values.
 16. A transaction system as recited inclaim 15 wherein said transaction terminal selects sets of digits fromthe account number of the transaction card which has been presented andgenerates a set of index values and wherein said index values are usedto determine if indicators are present in corresponding locations in thebit maps of the master table.
 17. A transaction system as recited inclaim 16 wherein the transaction terminal allows the transaction tocontinue unless an indicator is present in each bit map and in thatcase, the transaction is subjected to further verification.
 18. Atransaction system as recited in claim 15 wherein the length of each bitmap is set with respect to the number of invalid transaction cards suchthat the probability of an indicator being present in the bit map isapproximately 0.4 to 0.5.
 19. A transaction system as recited in claim13 wherein the number of bit maps in the master table are selected suchthat the probability of a valid card being represented as an invalidcard in the data file is less than ten percent.
 20. A transaction systemas recited in claim 13 wherein the number of bit maps in the mastertable are selected such that the probability of a valid card beingrepresented as an invalid card in the data file is on the order of oneto three percent.
 21. A financial transaction system including a centralprocessor and a plurality of transaction terminals and a plurality oftransaction cards each having an account number, and with some of saidcards being invalid, said system for facilitating off-line approval oftransactions comprising:means at said central processor for creating amaster table, said master table having data derived from a list ofinvalid transaction cards, said data being less than the entire accountnumber of each card and including at least one indicator for eachinvalid transaction card; means for supplying the master table to eachof the transaction terminals; and means at each transaction terminal fordetermining if an indicator exists in the master table for the accountnumber of the transaction card being presented and allowing thetransaction to continue if no indicator is present and subjecting thetransaction to further verification if an indicator is present.
 22. Atransaction system as recited in claim 21 wherein said means forsupplying the master table to the transaction terminals comprises:aradio transmitter; and a receiver located at each transaction terminal.23. A transaction system as recited in claim 21 wherein said mastertable includes a plurality of bit maps and wherein said means at saidcentral processor generates said master table by selecting sets ofdigits from the account number of each invalid transaction card andcalculating an index value for each set of digits which is analgorithmic function thereof and placing an indicator in individual bitmaps at locations corresponding to the calculated index values.
 24. Atransaction system as recited in claim 23 wherein said transactionterminal selects sets of digits from the account number of thetransaction card which has been presented and generates a set of indexvalues and wherein said index values are used to determine if indicatorsare present in corresponding locations in the bit maps of the mastertable.
 25. A transaction system as recited in claim 24 wherein thetransaction terminal allows the transaction to continue unless anindicator is present in each bit map and in that case, the transactionis subjected to further verification.
 26. A transaction system asrecited in claim 23 wherein the length of each bit map is set withrespect to the number of invalid transaction cards such that theprobability of an indicator being present in the bit map isapproximately 0.4 to 0.5.
 27. A transaction system as recited in claim23 wherein the number of bit maps in the master table are selected suchthat the probability of a valid card being represented as an invalidcard in the data file is less than ten percent.
 28. A transaction systemas recited in claim 23 wherein the number of bit maps in the mastertable are selected such that the probability of a valid card beingrepresented as an invalid card in the data file is on the order of oneto three percent.
 29. A transaction system as recited in claim 21wherein the entire master table does not have to be scanned to determineif an indicator exists for the account number of the transaction cardpresented for the transaction.